home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 001376_daemon _Mon Jun 21 01:02:50 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  3KB
  1. Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  2.     id AA26528; Mon, 21 Jun 93 01:02:52 MET DST
  3. Return-Path: <marca@wintermute.ncsa.uiuc.edu>
  4. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  5.     id AA26524; Mon, 21 Jun 93 01:02:50 MET DST
  6. Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  7.     id AA02810; Mon, 21 Jun 1993 01:24:46 +0200
  8. Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA16633
  9.   (5.65a/IDA-1.4.2 for www-talk@nxoc01.cern.ch); Sun, 20 Jun 93 18:24:37 -0500
  10. Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
  11.     for @newton.ncsa.uiuc.edu:www-talk@nxoc01.cern.ch id AA00795; Sun, 20 Jun 93 18:27:22 -0500
  12. Date: Sun, 20 Jun 93 18:27:22 -0500
  13. From: marca@ncsa.uiuc.edu (Marc Andreessen)
  14. Message-Id: <9306202327.AA00795@wintermute.ncsa.uiuc.edu>
  15. To: sanders@bsdi.com
  16. Cc: www-talk@nxoc01.cern.ch
  17. Subject: Re: launching executables through HTML files 
  18. In-Reply-To: <9306200334.AA01080@austin.BSDI.COM>
  19. References: <9306200334.AA01080@austin.BSDI.COM>
  20. X-Md4-Signature: 9cdb9b7ce78789eb2891f0c783c53244
  21.  
  22. Tony Sanders writes:
  23. > I think you should be able to configure the browser as to what MIME types
  24. > it should handle and which get passed to an external program.  Something
  25. > like the following (for X applications anyway):
  26. > 
  27. > XMosaic*contentTranslations: \
  28. >             #override            \n\
  29. >     text/html:    text_html()            \n\
  30. >     text/*:    text_plain()            \n\
  31. >     image/gif:    image_gif()            \n\
  32. >     image/jpg:    image_jpg()            \n\
  33. >     image/*:    exec(xv)            \n\
  34. >     video/mpg:    exec(mpeg_play -loop)        \n\
  35. >     audio/*:    exec(audio_play)        \n\
  36. >     exec/*:    verify_exec() exec(exec_handler)\n\
  37. >     */*:    unknown()
  38. > 
  39. > The #override means replace the translation table completely,
  40. > otherwise do a merge.
  41.  
  42. The reason I've held off doing that in general, believe it or not, is
  43. because I'm not sure what method to use.  I'd rather not invent a new
  44. method.  I may use mailcaps (RFC 1343).  ?
  45.  
  46. > Can anyone see that having a URL "exec:..." is better than simply
  47. > groking "content-type: exec/*"?  I think using content-type is
  48. > better because the "....:" part of a URL should specify how to
  49. > retrive the data, not what to do with it.
  50.  
  51. Except that one thing you're never going to do (at least, that I'm
  52. never going to want to let you do :-) is to actually retrieve
  53. executables over the net.  If you look at it from the point of view
  54. that the access method of a URL describes the process to be used to
  55. fetch data, then you could say that could be (a) a network protocol or
  56. (b) a local executable, without violating the metaphor.
  57.  
  58. I dunno... I still don't like the idea of firing off arbitrary
  59. executables on the client side, so I'm not gonna strenuously argue
  60. either way.
  61.  
  62. I take it by your use of the exec/* content type that the command to
  63. be executed would be in the data part of the message element and not
  64. in the subtype field of the content type, though, right?
  65.  
  66. Marc
  67.